🬤 rns.recipes

Forum / General / Thread / Export

# Help Testing: Interface Gravity

_General · started by Mark on Thu, Jul 23, 2026 5:16 PM_

---

## Original post

**Mark** · Thu, Jul 23, 2026 5:16 PM

The latest source version of RNS of Aleph introduces interface gravity configuration. From the manual:

The `gravity` option specifies the pathing affinity of an interface. If not set specifically, and unless otherwise configured by `default_gravity` or `autoconnect_interface_gravity`, it defaults to `0`. Positive values increase pathing affinity, and negative values decrease it.

This means, that each individual interface can now have a `gravity` value configured, and if multiple interfaces receive the same announce, the interface with the highest gravity wins the path table entry. This is especially useful for operators running transport nodes with public entrypoints, where many users continously connects and disconnects.

For example, since *some* programs have established a recent trend of just enabling transport by default on everything, this leads to situations where John Doe's phone is now part of your path, as he's strolling down the streets of Maryville. Phone is not doing much, and has a good fast connection right now, so as such, that's actually perfectly within the intended behavior of Reticulum - it delivers the announce most efficiently to the next transport node. Problem only is, in five minutes John enters the subway, and that path is gone.

(Okay okay okay, I know, the whole default transport thing *was* already fixed, but I'm just poking a bit of fun to illustrate the situation, and from what I can see, a lot of people *are* actually still running things like that, maybe intentionally, maybe not, who knows?)

Either way, with `gravity` this is much easier to just configure once, and then forget about. For example:

```

[reticulum]

default_gravity = 25 # Default high gravity for our static, known-good peers

autoconnect_interface_gravity = 15 # Prefer static, but higher priority to auto-connects too

[interfaces]

# Our internal downlinks gets the

# highest gravity, so paths nodes

# there are always reached directly.

[[Core Downlinks]]

enabled = yes

type = BackboneInterface

mode = internal

gravity = 50

device = enp2s0

port = 41862

block_fast_flapping = no

passphrase = udWaydHusBebyotEdLidveb3

# Two known-good high-performance

# backbone links, these inherit the

# default high gravity.

[[Backbone Peer 1]]

enabled = yes

type = BackboneInterface

mode = gateway

remote = some.host.tld

target_port = 4242

[[Backbone Peer 2]]

enabled = yes

type = BackboneInterface

mode = gateway

remote = other.place.tld

target_port = 4242

# Our public entrypoint is open to

# the chaos of the world, so this

# gets a lower gravity than the rest.

[[Public IPv4]]

type = BackboneInterface

mode = gateway

gravity = 10

enabled = yes

device = enp1s0

port = 4242

```

It's worth noting that the gravity mechanisms are currently (and intentionally) rather rudimentary. Once the core concepts have been tested, and probably adjusted a bit, it will serve as the basis for much more intelligent behavior, and is a required part of the picture before multi-pathing and path redundancy.

Please also see the other post I just made about dynamic path re-balancing. Any help testing all of this out on transport nodes across the network is much appreciated!

PS: *If you, for reasons related to the above, cannot access the latest source code on Aleph, I posted a pre-compiled test wheel here:*

https://github.com/markqvist/Sideband/releases/download/1.9.8/rns-1.4.0-py3-none-any.whl

---

## Reply 1

**welo** · Thu, Jul 23, 2026 6:44 PM

Connecting to nomadnet sites seems to a little more snappy on my backbone server which I'm guessing gravity is responsible for out of the two changes in this version because I won't default to going through some random connection on my public interface.

Question, would it make sense to give a lower gravity to lower bitrate and higher latency interfaces such as I2P or LoRa if you are serving a public interface for either? Would that decision still make sense if you were not a transport node?

---

## Reply 2

**Mark** · Thu, Jul 23, 2026 8:07 PM

Interface gravity can definitely be used on non-transport nodes and normal devices as well to better control the pathing affinity according to whatever you like. For low-bandwidth/high-latency interfaces, it's probably not going to change the pathing decision much in practice though, since path will almost certainly end up going over faster/lower-latency interfaces if destinations are reachable there anyway. But if you have specific needs in that regard, no harm in experimenting with what works best.

---

## Reply 3

**Anonymous** · Fri, Jul 24, 2026 5:45 AM

Sounds very useful, but I dont fully understand the example. Where would the transport node phone be connected in the config given, and how would interface gravity help here exactly?

---